OpenEdge Application Server:<br />Developing AppServer Applications Connect and disconnect performance issues

This section discusses performance issues related to connecting to and disconnecting from AppServers.

As with any computer architecture that uses remote-procedure-call technology, the time that it takes to make a connection can be costly. This initial startup time is increased when you use an AppServer Connect procedure.

Using the AppServer Connect procedure

The AppServer Connect procedure provides a convenient place to perform connection activities. Although these connection activities have value for a variety of reasons, be aware that using these could, to various extents, affect your overall connection performance.

You might want to perform any of the following activities independently of each other, or in combination with any other items:

Authenticate and authorize based on additional parameters you can pass to the Connect procedure (user-id, password, and/or app-server-info).

For a state-reset or state-aware AppServer, provide security for procedure execution by using the EXPORT( ) method to define the allowed export list for client applications.

Note: For a stateless AppServer, you probably want to set the export list in the Startup procedure.

Connect to one or more databases, or to other AppServers on a state-aware or state-reset AppServer.

Initiate application-specific audit trails and/or activity logs.

It might be difficult to predict exact connection speed and the effects of using any, all, or some combination of these options. However, in general, each of these options has some overhead. Although none of these options are required, you might want to consider them as part of your security model. See the "Security considerations" section for more information.

Performance-related issue for the CONNECT( ) method

Connecting to session-managed AppServers can be expensive depending on agent startup and initialization tasks defined in your AppServer Connect procedure. Connecting to a session-free application service can be expensive depending on the number of initial connections and NameServer responsiveness on the network. For these reasons, you might want to connect to AppServers at client application startup. Also, in most designs, it is advisable that you do not disconnect from AppServers if you intend to use services offered by a particular AppServer more than once prior to ending the client application session.

Performance-related issues for the DISCONNECT( ) method

On a state-reset or state-aware AppServer, the DISCONNECT( ) method has no significant performance impact on your client application regardless of whether there is an AppServer Disconnect procedure defined. The AppServer Disconnect procedure is run by the AppServer after the client connection is terminated and DISCONNECT( ) method execution has completed. That is, unlike other procedures executed in an AppServer session, the AppServer Disconnect procedure is run by a state-reset or state-aware AppServer concurrently with processing occurring in the client application.

For a state-reset or state-aware AppServer, you might be able to take advantage of the way the AppServer Disconnect procedure is run to improve overall application performance. When designing your distributed application, consider tasks to be performed by an AppServer that could be performed independently of the connection between the client application and the AppServer. These tasks would typically be ones where the client application does not require any information about the success or failure of the operation. Time-consuming actions are very good candidates for consideration. By moving these tasks to the AppServer Disconnect procedure, these actions can be performed concurrently with other client application processing, improving overall application performance.

On a stateless AppServer, any defined Disconnect procedure runs before the client connection is terminated. Thus, especially for frequent and short-duration connections, you probably want to ensure that the Disconnect procedure does not perform any processing that significantly delays the execution of the DISCONNECT( ) method. This can both impact the client and delay the availability of an AppServer agent.

In a session-free application (state-free operating mode), the DISCONNECT( ) method has minimal performance impact because no Disconnect procedure is executed.